Addressee-defined mail addressing system and method

ABSTRACT

A mail delivery system and method for delivery of mail to addressees are disclosed. The system is particularly suitable for implementation in the context of an email or similar electronic messaging system, and is particularly useful for managing and/or discouraging unsolicited junk mail. The system comprises a plurality of unique delivery addresses, each for a corresponding addressee, and a plurality of delivery codes. The delivery codes are generally defined or otherwise controlled by the addressees, with each addressee controlling a specific subset of the delivery codes. Any given delivery code does not comprise a unique delivery address or any essential portion thereof, and instead comprises distinct, essentially arbitrary addressee-controlled information. The method comprises addressing a selected piece of the mail with a selected delivery address, and associating a selected delivery code with the selected delivery address of the piece of mail. The selected delivery code may be (and from the mail sender&#39;s viewpoint, preferably is) one defined by the addressee of the particular piece of mail. The method further comprises delivering the piece of mail to the addressee if the delivery address is associated with a valid delivery code defined by the addressee, and dispatching the piece of mail as directed by the addressee, if it does not have a valid, addressee-defined delivery code. For example, mail lacking a valid delivery code may be deleted or destroyed without delivering to the addressee. The system further comprises means for performing steps of the method, such as an application operable in a computer memory.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority pursuant to 35 U.S.C. § 119(e) to U.S.Provisional Application No. 60/204,723, filed May 16, 2000, whichapplication is specifically incorporated herein, in its entirety, byreference.

COPYRIGHT NOTICE

This patent document contains material subject to copyright protection.The copyright owner, Ideaflood, Inc., has no objection to thereproduction of this patent document or any related materials, as theyappear in the files of the Patent and Trademark Office of the UnitedStates or any other country, but otherwise reserves all rightswhatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to systems and methods for delivering andreceiving mail, particularly electronic messages, such as electronicmail (email) and voice mail as used in electronic messaging oncommunications networks. More particularly, the invention relates to anaddressee-defined addressing system and method for creating and usingmail addresses in a mail system.

2. Description of Related Art

Postal services and mail have long been important to the functioning ofcivilized societies. With the rise of communications networks andelectronic messaging, and particularly, the increased use of computernetworks such as the Internet, the volume and importance of email havebecome very important, perhaps even eclipsing traditional postalservices. However, being in a sense merely another form of mail, emailhas become plagued with problems and limitations that are also found intraditional mail systems. In some cases, problems with traditional mailsystems are exacerbated in email and other electronic messaging systems.

One such problem that vexes users of traditional and email alike is thebulk distribution and receipt of unsolicited “junk” mail. General mailsystems are by nature freely available to all potential senders of mail,thereby permitting a free flow of information. Consequently, certainsenders of information, such as commercial advertisers, politicaladvocates, and fundraisers, find it advantageous to send unsolicitedmail in bulk to many addressees, even though the percentage ofaddressees that will respond to the unsolicited mail, i.e., the“response rate,” may be quite low. Generally speaking, the incrementalcost of sending unsolicited mail is related to the response rate thatthe mail sender must achieve to justify the bulk mailing. In traditionalmail systems, the incremental cost of mailing has limited unsolicitedmail somewhat. Junk mail may be bothersome to those served bytraditional postal services, but it is rarely a serious problem. In asense, postal service junk mail may even benefit postal users, becausethe postage fees generated by the high-volume mailings contribute tofunding the postal system.

However, some email or messaging systems are “freemail” systems in thatthey are open mail systems in which senders are not charged based on thequantity of mail sent and the incremental cost of sending a message isessentially zero. In a freemail system, there is essentially no economiclimit to the volume of unsolicited mail that a sender may findprofitable to send. Internet-connected email systems are a primaryexample of a freemail system. Consequently, junk mail has become aserious problem on many email systems, in many cases threatening tooverwhelm entire systems and often causing the closure of individualemail accounts. Various automatic filtering methods have been devisedfor identifying and segregating or deleting unsolicited junk mail, butall of these systems suffer from the disadvantage of requiringsubstantial system overhead for performing the identification andfiltering tasks. Furthermore, such methods are often easily circumventedby those desiring to send junk mail. Because not all unsolicited mail isundesired, filtering systems also prevent the delivery of some desiredmail. Accordingly, junk mail remains a serious unresolved problem onemail systems.

The deluge of junk mail on email systems has led to another problem.Knowing that many websites will sell their email address as part of anaddress list, thereby leading to the receipt of undesired junk mail(sometimes called “spam”), users may provide separate, essentiallyunused email addresses when registering at commercial sites, or in thealternative, avoid registering any address with websites at all. Suchpractices may prevent the user from receiving unsolicited mail, but alsoprevent much desirable electronic communication, and may cause adecrease in desirable electronic commerce. For example, a user mayprovide an unused email address to his phone company, out of fear thatthe phone company will sell the address to others, and then fail to readan urgent message from the phone company warning of a shut-off ofservice for lack of payment. For further example, a user may decide tonot visit a website because an email address is required to accesscertain content, and then fail to discover that the website hasinteresting content, or offers other valuable products, that the userwould have been willing to pay for. Thus, these examples illustrate howconcerns over unsolicited email may indirectly hinder electroniccommerce and the use of email systems for important communications.

Another problem common to both traditional and electronic messagesservices is sorting of mail based upon the category of the sender. Mailaddressees of both types of services have to sort their own mail. Forexample, a common secretarial task is to separate junk mail fromimportant business correspondence. It would be much more convenient foraddressees if mail were delivered in bundles sorted according tocategory of sender, for example “commercial mail from known accounts,”“mail from XYZ Corp,” mail from friends,” “mail from family,” “mail fromunknown senders,” and so forth. Not only would such sorting save theaddressee time, such sorting, if carefully executed, might effectivelyeliminate junk mail from the mail system. Of course, motivating atraditional postal service to sort mail in this way is not a trivialtask. Email systems generally do sort mail, on the other hand, buteither use sorting methods of relatively small benefit (for example, byalphabetizing mail by sender name), or are subject to the limitationsand problems associated with the prior art email filtering systemsdescribed above.

Therefore, a mail system that overcomes these limitations and problemsof prior art systems is desired. It is further desired that the mailsystem be readily adapted for use with email systems in use on wide areanetworks such as the Internet, and similar electronic messaging systems.

SUMMARY OF THE INVENTION

The present invention provides an innovative addressee-defined mailaddressing system that overcomes the limitations of prior art emailrouting and filtering systems. In particular, the system elegantlyresolves the problem of unsolicited junk mail while providing mailaddressees with a convenient way to organize and sort their mail. Thesystem may be readily adapted for use with existing mail systems, andparticularly with email systems commonly used on or connected to theInternet, while requiring minimal system overhead. When implementedaccording to one of the preferred embodiments, the system is difficultor impossible for senders of bulk unsolicited mail to circumvent. Thesystem will be particularly appreciated by discriminating, knowledgeableusers of the Internet, and it is believed that the system will encouragesuch users to rely more heavily on email as a critical method ofcommunication, and to more freely engage in electronic commercetransactions without reservation.

In general, the addressee-defined addressing system comprises aplurality of addresses and a way to deliver mail according toinformation in an address associated with each piece of mail. Eachaddress of the plurality of addresses contains a unique delivery addressthat is sufficient to uniquely identify an individual addressee. As usedherein, “addressee” means any entity with the primary right to receivethe contents of mail messages delivered to a uniquely identifieddelivery destination, and is not necessarily limited to individualpersons (although in many cases the addressee is an individual person).Therefore, addressees do not include forwarding agents, mail servers,post offices, and other intermediate destinations along a mail route.

According to the invention, each address of the plurality of addressesmay optionally contain a delivery code that is distinct from the uniquedelivery address. A delivery method operates as follows. Any piece ofmail not addressed with a fully qualified address portion is processedas not addressed to an identifiable addressee. For example, the mail maybe returned to the sender. Any piece of mail addressed with a uniquedelivery address but not containing a delivery code is also dispatched,preferably as directed by the addressee. For example, the mail may bedispatched by being discarded, by being returned to the sender marked aslacking a delivery code, or by being delivered to the addressee markedor classified as lacking a delivery code. Preferably, the addressee mayspecify a change in the dispatch method at any time.

Any piece of mail addressed with both a unique delivery address and avalid delivery code is delivered to the addressee according to adelivery rule. The delivery code is considered valid if previouslydefined (i.e., set-up and/or approved) by the addressee, and not laterinvalidated by the addressee. The delivery rule may consist essentiallyof simple delivery to the addressee. However, the addressee maypreferably specify additional operations, such as sorting or classifyingthe piece of mail according to the delivery code. Preferably, theaddressee may define or invalidate any number of delivery codes, at anytime.

In an embodiment of the invention, the addressing system is applied toan email system, as illustrated by the following example. Various emailsystems and protocols exist, but most share the following generalcharacteristics. A format for addressing each email message and addressinformation is generally specified. The address generally comprises aname identifying the network location of a destination domain, forexample, “xyzcorp.com,” plus the name of an account, for example,“johndoe,” on the destination domain. The destination domain may beserviced by one or more physical servers, or several domains may beserved by a single server. In either case, the entire address, such as,continuing the foregoing example, “johndoe@xyzcorp.com,” comprises aunique delivery address, and accordingly, only one “johndoe” can bepermitted in the domain “xyzcorp” or any other particular domain.Generally, an email account administrator prevents creation of duplicateaccount names within a particular domain, thus protecting the uniquenessof each account name, so that the account and domain names together canserve as unique delivery addresses. Furthermore, although differentemail systems may divide account names variously, for example, theaccounts “john.doe” and “bob.doe” may coexist on the same domain in somesystems, according to the prior art each of these dot-divided namesidentifies a different, unique account. Various email systems may routeemail in different ways, such as through different mail servers andgateway servers. However, the basic address format of a domain or servername in conjunction with an account name is widespread, although theinvention is not limited thereby.

The present invention may be adapted for use with these commonly usedaddress formats. Prior art email addresses may essentially become aunique delivery address or “root address” of the present system by theaddition of a delivery code, such as, for example, a dot-divided prefix.For example, “johndoe@xyzcorp.com” may become“sallyg.johndoe.xyzcorp.com,” where “sallyg” is the delivery code andthe remainder of the address is the root. According to the invention,the mail server will recognize “sallyg” or any other address prefix asbelonging to the account “johndoe,” and not as a separate addresseeaccount “sallyg.johndoe.” In the alternative, the delivery code may beassociated with (and separated from) the root address in any othermanner, such as by a combination using some other separation character,or by placement on a separate line or in a separate field of the email.Preferably, each email account holder may freely define any number ofdifferent delivery codes at any time, for example, “fredm,”“companyabc,” “phonecompany,” and so forth. Any such addressee-definedcode will be recognized by the mail delivery system as belonging to the“johndoe” account.

According to an embodiment of the invention, when providing an emailaddress to others in a system according to the invention, each accountholder may provide, and usually will provide, a selected delivery codethat appears as part of the email address, such as a prefix.Furthermore, the holder's mail server is preferably configured to ensurethat the return email address always includes a delivery code, either byprompting the account holder to supply a selected addressee-definedportion, or by supplying a default addressee-defined portion. Therefore,most or all persons desiring to send email to a particular account willpossess a root address and at least one delivery code, that may appear,for example, as a prefix to the root address. Such senders may thus bedisposed to generally use what appears to be a complete regular emailaddress (including both the root and prefix portions) in addressing mailto the account. For example, most email addresses are not obtained bymanual entry or inquiry, but are instead automatically obtained from thereturn address field of an email message or from entry by a prospectiveaddressee in a database, such as during a user registration process.Thus, whatever form of address is provided will subsequently be used foraddressing mail to the account.

When mail addressed to a particular account as described above isdispatched by a mail server configured according to the invention, themail is handled differently according to the prefix portion of theaddress. In an embodiment of the invention, the mail may be sorted intoseparate folders labeled according to the addressee-defined deliverycode. For example, mail addressed to “sallyg.johndoe@xyzcorp.com” may beplaced into a folder labeled “sallyg” in the “johndoe” account holder'semail directory.

Mail that lacks a addressee-defined prefix portion, or contains anobsolete, incorrect, or otherwise invalid prefix, may be deleted, orplaced in a separate folder with a label indicating that no validaddress prefix was provided. Such disposition is preferably as directedby the addressee. It may additionally be preferable for the mail serverto automatically send a reply message to the sender of such mail. Theautomatic reply message may identify the addressing error (lack of aprefix or invalid prefix), and notify the sender that the message willnot be delivered to the account, or will be placed into a suspensefolder.

When reviewing email, the account user (addressee) preferably may view adirectory of prefix folders, with the folders containing new or unreadmail preferably flagged or highlighted. The user is then free to reviewmail in any folders of interest, to ignore other folders, or tootherwise prioritize the viewing of mail based on its organizationwithin the folders. Thus, the addressee-defined email address system mayoperate as the key to a mail organizing system, and each address prefixadditionally may operate as a kind of password for obtaining theaddressee's attention.

Further beneficial uses of the present addressing system are illustratedby the following examples. One use of the system is for identifyingentities that have distributed an email address for purposes of sendingunsolicited junk mail, and in addition, the specific receiving entitiesthat a particular distributing entity has sold or transferred theaddress to. For example, a user may supply the email address“phoneco.johndoe@xyzcorp.com” to the user's phone company. If the usersubsequently receives unsolicited, undesired mail from the phonecompany, and especially from other companies or entities, which isaddressed using the “phoneco” prefix, the user knows that the addresswas obtained from the phone company. The user may then take appropriateaction, such as complaining, requesting that the address be keptprivate, terminating the relationship with the phone company, or even,where permitted by law, filing suit against the phone company. The usermay also delete or make obsolete the “phoneco” prefix, so that nofurther mail addressed using this prefix will be delivered. If theoriginal phone company recognizes that the prefix/root address structuremay make its use of the address traceable, it may be more likely to keepthe address private. Thus, once the invention is implemented and itsfunctional features are widely recognized, the present invention isanticipated to generally deter inappropriate sharing and use of emailaddresses for sending unsolicited mail by serving to identify the partyresponsible for distribution of an email address.

The invention also enables email users to conveniently and quicklyeliminate and set up mail folders for purposes such as managingunsolicited mail. For example, if a particular folder receives too muchunsolicited or otherwise undesired mail, the addressee may simply deletethe corresponding address prefix. Any subsequent mail addressed with thedeleted prefix is then dispatched by the mail system as directed by theaddressee. The user may quickly replace the prefix with an alternativeprefix to receive desired mail in the same category.

Bulk senders of unsolicited mail, sometimes called “spammers” in emailparlance, will find it difficult to circumvent the system. Circumventionrequires knowing or guessing at least one valid delivery code for everyunique delivery address to be spammed. While a spammer may employ arobotic mail agent programmed to generate addresses containing prefixesof commonly used words, such a strategy will only be successful if mostaddressees use prefixes that are easily guessed, perhaps such as“friends.” However, it is anticipated that such guessing strategies maybe easily frustrated by choosing less easily guessed prefixes, perhapssuch as “4mypals!”.

Although the primary applications of the invention are anticipated to beto public freemail systems, such as Internet-connected email systems,the invention is not limited thereby. To the contrary, the innovativeconcepts of the invention may be applied to a wide variety of mailsystems, even, for example, traditional postal services. A hypotheticalimplementation in a postal service is illustrated as follows: a mailaddressee at a fully qualified postal address, such as an individual ata street address, may supply delivery codes to different entities, suchas, for example, “Company X,” “My Friend Fred,” and so forth, withinstructions to include the code in the address of all mail to theaddressee. The mail addressee would then set out separate mailboxes atthe street address, each labeled with a corresponding delivery code. Thepostal carrier would be required to sort mail delivered to theaddressee's street address according to the delivery codes, and placecoded mail in the correspondingly-labeled box. Uncoded or improperlycoded mail would either be placed in a separate general mail boxprovided by the addressee for this purpose, or if the addressee providedno general mail box, returned to the sender. The postal addressee wouldthus have total control over which mail is received, based on the mailsender, without any need for the addressee to review the mail. Forexample, if the addressee no longer wished to receive mail from CompanyX, the addressee would simply remove the corresponding Company Xmailbox; if the addressee only wished to receive junk mail onWednesdays, the addressee would only set out the general mail box onWednesdays; and so forth. The foregoing example is not meant to suggestthat implementation in a traditional postal service would beparticularly practical, or as beneficial as application to an emailsystem. However, the hypothetical example does serve to illustrate thepotentially wide applicability of the pioneering concepts describedherein.

A more complete understanding of the addressee-defined mail addressingsystem will be afforded to those skilled in the art, as well as arealization of additional advantages and objects thereof, by aconsideration of the following detailed description of the preferredembodiment. Reference will be made to the appended sheets of drawingswhich will first be described briefly.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram showing elements and operation of a mailaddressing and delivery system according to the invention.

FIG. 2 is a block diagram showing core elements of a mail addressing anddelivery system according to the invention.

FIG. 3 is a flow chart showing exemplary steps of a method fordelivering mail according to the invention.

FIG. 4 is a flow chart showing exemplary steps of a method for providingan addressee an option to define and revise delivery codes according tothe invention.

FIG. 5 is a flow chart showing exemplary steps of an alternative methodfor providing an addressee and option to define delivery codessemi-automatically.

FIG. 6 is a schematic diagram of an exemplary view screen for use with asystem and method according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention provides a system and method for addressing anddelivering mail that overcomes the limitations of prior art mailsystems. In the detailed description that follows, like element numeralsare used to indicate like elements that appear in one or more of thefigures.

Referring to FIG. 1, a mail system 100 comprises a plurality of mailboxes, such as mail boxes 104 a-d for receiving mail, and a method forsending, receiving, and performing other operations upon mail exchangedbetween mailboxes. Various methods and/or systems may be used forhandling of mail, such as, for example, a network of computers employingat least one mail server in connection with a plurality of clientcomputers; a physical letter-carrying system; or a communicationsnetwork comprising a transmission medium (such as fiber optics lines,wire, satellites, or radio cells), switches and a plurality ofcommunication devices (such as telephones and/or facsimile machines)capable of sending, receiving, and storing messages. The present systemand method may be implemented in any of such various systems by atechnician of ordinary skill in the relevant art. Implementation in amail server of a computer network is believed to be a particularlyuseful application of the invention.

Each of mailboxes 104 a-d (four of many shown) belongs to acorresponding addressee 102 a-d with one of the corresponding deliveryaddresses 106 a-d. Each of the addresses 106 a-d should be consideredprimarily a system attribute, because each address is unique withinsystem 100, although addressees may have a limited power to determinetheir address. Such is illustrated by the example of networked mailservers, each of which is provided with a unique network address througha registry system. Each server then may maintain a separate registry ofunique account names. Each account name plus a mail server addresscomprises a fully qualified address for identifying a particularaddressee (or in the case of joint addressees, a particular group)according to a mail sender's delivery intentions. Whether or not thereis more than one person or other user at a particular address, eachsystem address (e.g., each of addresses 106 a-d) nonetheless designatesa sender's delivery intent. For example, mail addressed to the “DoeFamily” may be received by, and only by, any member of the family; andthus the family Doe is the addressee. Furthermore, it is well known thatmail addresses may be subdivided in various ways, for example, by addingapartment, suite, or box numbers, or in the case of email addresses, bylengthening a root name such as “doe” by adding additional characterssuch as “john” or “sue.” However, such subdivision is performed toenable senders to direct mail to a particular person or persons.Accordingly, such subdivided addresses are merely another form of uniquedelivery address, and are primarily a system-controlled attribute.

At least one addressee of system 100, for example, addressee 102 a, maydevise any number of delivery codes 108. For each delivery code, such asa first code 110, the addressee may establish a box, folder, or othersuitable partition for organizing mail in mailbox 104 a. For example, inan email system, the first code may be a string of characters such as“4mypals” and the folder 112 may be a correspondingly labeled directoryfolder of the addressee's mail directory. Mailboxes may also have otherorganizing partitions, for example, the “general inbox” folder 114 ofmailbox 104 a. In an email system, a particular addressee's deliverycodes, such as codes 108, may be maintained in a list or other databaseon the addressee's mail server or client device. However, the deliverycodes belonging to a particular addressee are controlled and maintainedat the direction of the addressee, and not a system administrator. Thedelivery codes are also maintained as confidential to the addressee,meaning that the addressee alone is permitted to divulge them to others.Being comprised of a string of characters, each delivery code may becombined with a root delivery address of an email system, making thecombined address appear as a subdivided address. For example, “4mypals”may be combined with “johndoe@xyzcorp.com” to appear like the subdividedaddress “4mypals.johndoe@xyzcorp.com.”

Operation of system 100 is illustrated by the following example.Addressee 102 a, for example, “John,” divulges delivery code 110 in acombined address 116 provided to addressee 102 b, for example, the“PhoneCo.” PhoneCo subsequently sends a piece of mail 118 addressed withthe combined address 116, which is delivered to mailbox 104 a belongingto John and placed in the folder 112 corresponding to the delivery code110. John, upon reviewing the contents of mailbox 104 a, sees the mailfrom PhoneCo in folder 112 and assumes it to be a phone bill. PhoneCoimproperly divulges the delivery code 110 in combined address 116provided to a third addressee 102, for example, “SalesCo.” SalesCo sendsa sales solicitation letter 120 addressed with the combined address 116,which is delivered to mailbox 104 a and placed in folder 112. John seesthe mail from SalesCo in the PhoneCo folder 112 and assumes it to beunsolicited junk mail. John also realizes that SalesCo could have gottenthe delivery code 110 only from PhoneCo, because John had not disclosedit to anyone else. John therefore may, if desired, send a message toPhoneCo to complain about their improper disclosure of the combinedaddress 116. Meanwhile, a fourth addressee 102 d, for example,“CluelessCo,” obtains John's public root email address, and sends asales solicitation letter 122 addressed only with the root deliveryaddress 106 a. In an embodiment of the invention, this mail is deliveredto John's general inbox 114, where it sits unread because John receivesa huge volume of junk mail and seldom any important mail in the generalinbox 114, so this folder is seldom checked unless John somehow learnsthat someone sent him important mail addressed without a delivery code.After sitting unread in folder 114 for a period of time, the message 122is discarded. The same result may be obtained if a letter is deliveredto a mailbox with an invalid code, such as if CluelessCo attempts toguess at a valid delivery code (but fails to guess correctly), or usesan obsolete code. In the alternative, the message may be “bounced” fromJohn's mailbox by returning to the sender, optionally accompanied by amessage stating a reason for the return. Or, some combination ofbouncing the message and placing in a junk mail folder may be employed.

FIG. 2 shows a block diagram of a delivery system 200 according to theinvention. Delivery system 200 comprises four primary elements:addressing function 220, code association function 240, deliveringfunction 260, and dispatching function 280. These functional elementsare not necessarily performed by distinct apparatus or in separatesteps, but rather represent key functional aspects of the presentinvention. The addressing function 220 accomplishes the addressing ofmessages according to defined rules. For example, the defined rules maycomprise postal service addressing regulations, and the method ofaddressing may comprise writing the address on the exterior of a letter.In an email system, various rule systems are known for addressingmessages, for example, Simple Mail Transport Protocol (SMTP). The methodof addressing may comprise inserting the address into the appropriatelocation in a file, and is normally performed by an applicationoperating in a computer. The addressing function may comprise stepsperformed at different system levels, for example, by a client using aweb browser or mail interface program, by an outgoing mail server, or bya gateway server to a different network.

Code association function 240 accomplishes association of delivery codeswith root delivery addresses. Like addressing, consistent rules for suchassociation are needed. Such rules may be considered part of addressingrules, but are mentioned here separately to highlight the importance ofthe addressing scheme of system 200 being compatible and associable withthe delivery codes. For example, in an email system delivery codes maybe incorporated as prefixes to root addresses, separated by a charactersuch as a dot. In the alternative, delivery codes may appear in aseparate address field or line. However, a prefix format is believedpreferable for compatibility with existing email addressing protocols.Association using a prefix structure provides the advantage of allowingthe combined address to be handled by system 200 as though it were asubdivided, regular address.

Delivering function 260 accomplishes routing and delivery of anaddressed message bearing a full address (including a valid deliverycode) to a designated location in an addressee mailbox. Again, variousmethods and systems are known for delivery of a message according toaddress information. One skilled in the art may adapt such methods toincorporate the functional aspects of the present invention. Inparticular, such methods should be adapted to ignore the delivery codesof the invention except at the point of delivery to an applicantmailbox. Additionally, the delivery function should include checking thevalidity of delivery codes against a list of valid codes maintained by aparticular addressee, and organizing the delivered mail according to theaddressee's delivery codes. For example, in an email system using aSMTP-like protocol, any dot-divided prefixes would be essentiallyignored until the message reached the destination mail server. Then, thedestination mail server would obtain the delivery code list belonging tothe root address, determine whether the message address contained avalid delivery code, and if so, place the message in the addressee'sinbox folder in a subdirectory (folder) belonging to the correspondingdelivery code.

Dispatching function 280 parallels the delivery function, but is fordisposition of mail that lacks a valid delivery code. Function 280 mayoperate essentially the same as delivery function 260, except after themail has been delivered to the root address. Thus, in an email system,the novel aspects of the dispatch function 280, like the other novelaspects of system 200, may be performed primarily or even entirely on amail server at the root domain. It is anticipated that the ability toperform the novel aspects of the invention on a server at the rootdomain makes the invention highly compatible with existing emailsystems. In addition, the invention may be implemented modularly, thatis, mail servers that operate according to the invention will becompatible with, and may operate as part of, a mail system that alsoincludes mail servers not configured according to the invention. Afterdelivery to the addressee's mail server or other local delivery agent,the dispatching function obtains the addressee's dispatching rule (e.g.,“discard message,” “place in general invalid code folder,” “return tosender,” “inform sender,” or some combination of the foregoing) anddispatches the message accordingly. Thus, in an embodiment of theinvention, a result of the operation of the dispatching function may bevery similar to (except for the label of the delivery folder) to that ofthe delivering function. However, even this slight difference mayprovide the addressee with the benefits of the invention, in that oncethe messages lacking valid codes are segregated, the addressee mayconveniently ignore them. Additionally, the dispatching rule may varyaccording to the circumstances. For example, if the delivery code usedby the sender was once a valid code, but has been changed, a message tothis effect may be returned to the sender. In comparison, if the senderhas not provided any delivery code, or has used an unrecognized code, adifferent message may be returned to the sender.

In general, as part of the dispatching rule 280, it is preferable toperform at least one of returning the original message or returning anotice of invalid code to the sender, thereby ensuring that the senderdoes not falsely assume that the message was delivered normally. Desiredcorrespondents, upon receipt of a returned message and/or notice, willgenerally have some other way (such as a phone call) of contacting theaddressee and thus obtaining a valid delivery code. Undesiredcorrespondents will be unable to obtain a valid delivery code, and willbe made aware that their unsolicited mailing was ineffective. Theadditional actions of retaining a copy of the message in a separatefolder or other location (or marked to indicate an invalid deliverycode) may be combined in various ways with other actions, preferably atthe option of the addressee.

FIG. 3 shows exemplary steps of a method 300 for delivering mailaccording to the invention. In an initial step 302, a piece of mailbearing an address is received. Various methods may be used to send thepiece. For example, a sender may place an article of mail in a mailboxfor pick-up, such as the outgoing mailbox of a mail server, by selectinga “send” command in an email application. The addressee address (oraddresses, if there is more than one addressee) is read at step 304. Atstep 306, the completeness of the address is determined. Portions ofstep 306 may be performed at different points in a mail system. Forexample, a first email server may determine that the destination domain,such as “xyzcorp.com” exists and is available to receive mail. A secondemail server at the destination domain would then determine whether theaddressee name, such as “johndoe,” is a valid account on the mailserver. Failure of either condition will cause the message to bedispatched at step 308 according to a system rule for dispatchingimproperly addressed mail. For example, the mail system may return thepiece of mail to the sender with an error message.

At step 310, if the address meets the minimum criteria for completeness,the piece of mail is checked for the presence of a valid delivery code.This step will typically occur at the destination side of the mailroute, such as by a destination mail server or post office. The deliverycode is first identified, such as by reading an address prefix orscanning a field set aside for delivery codes. Preferably, only onedelivery code per message and per addressee is recognized. Thispreferable limitation does not conflict with another preferred aspect ofthe invention: that delivery codes may be subdivided to facilitate ahierarchical organization scheme, such as a directory structure. Anydelivery codes that are recognized as associated with the mail message(preferably, a maximum of one) are then compared against a list of validdelivery codes from an addressee-supplied list. The list of valid codesmay be obtained in various ways, for example, by querying a databasemaintained for this purpose, or by examining an addressee mailbox andreading its folder labels. If a match is discovered, the code isvalidated. If no match is discovered, the message is dispatchedaccording to an addressee-supplied rule, which may be supplied like thelist of valid delivery codes. As previously described, typical dispatchrules may include “return to sender,” “send error message to sender,”“discard,” and/or “segregate in a folder.”

If the message bears a valid delivery code, it is delivered to theaddressee at step 314 according to a delivery method as known in theart. Preferably, the piece of mail is placed into an addressee mailboxorganized by code at step 316. Of course, organization may beaccomplished in a computer system by merely displaying a list ofmessages sorted by delivery code. Some users may prefer to have messagesplaced in an appropriate folder of a directory as determined by thedelivery code. The particular folder and/or directory tree may then behighlighted and/or flagged to indicate the presence of a new, unreadpiece of mail. Other users may prefer that all the messages, or in thealternative, all of the messages having valid delivery codes, be placedin a single folder, organized in a list format such as in reversechronological order. In a list format, the delivery code used by eachmessage may optionally be listed or otherwise indicated (such as by anicon) on or adjacent to each item in the list. The user may then quicklyscan all of the messages received to identify those of highest interest.Additionally, some users may desire to archive some or all of themessages in selected folders, after having reviewed them. Preferably,the user may specify the desired mode of presentation and/or archiving,and toggle between different presentation modes at will.

In an embodiment of the invention, delivery codes may facilitatehierarchical organization of messages. For example, a message having asubdivided delivery code consisting of “ted&sal.4mypals” may be placedin a “ted&sal” folder of a “4mypals” directory Method 300 may then berepeated in order for the next piece of mail received. Because deliverycodes are preferably addressee-controlled, and may be used to primarilyindicate a sender or category of senders, the invention thus providesfor the organization of mail by category of sender. Additionally, themail messages may be organized by other principles, such as inalphabetical order by the sender's subject line or in chronologicalorder, as known in the art.

FIG. 4 shows exemplary steps of a method 400 for providing an addresseean option to define and revise delivery codes according to theinvention. Providing addressee control over delivery codes is animportant aspect of the invention. Method 400 is intended to operate ina system where a mail server or other delivery component of the systemmaintains a list or database of valid codes for at least someaddressees. Accordingly, the method requires a preparatory step (notshown) of preparing the lists or database, and providing procedures forits operation. At step 402, an addressee request is received by theagent, such as an application operating on a mail server, responsiblefor maintaining the addressee database of delivery codes. In anembodiment of the invention, a user interface of an email systemprovides a function for administering the user's delivery codes. Theuser would issue the request referred to by opening the administrativefunction and selecting an appropriate command. After the request isreceived, the requestor's list of established delivery codes is opened,such as by retrieving the list in a computer memory or connecting to adatabase, as known in the art.

Three typical requests that may preferably be accommodated includeadding, revising, or deleting a specified delivery code. If, at step406, it is determined that the request is to add a code, the requestedcode is added to the list at step 408. This may be done by providing anappropriate data field for the user to enter the desired new deliverycode. The requested new code is preferably validated by comparing withthe addressee's other established delivery codes, to ensure that it isnot a duplicate of an established code. Additionally, the requested newcode may be checked for the presence of characters or character stringsthat are forbidden or discouraged by the mail delivery system, such asspecial characters reserved for system use, and for proper syntax. Iferrors are discovered, the system preferably prompts the user to supplya different code. The system may provide a mailbox folder labeled withthe new delivery code after the code has been thus established.

When setting up a new delivery code, the user preferably may be giventhe option of characterizing the delivery code by associating relatedinformation. For example, the date and time that the delivery code isestablished may be recorded in a database of delivery codes. The usermay, in addition, desire to record the identity of other parties to whomthe address is given to so as to better keep track of its use, and/or tomake a note of any explanatory comments. These and similar informationmay readily be recorded in a database at the time a delivery code isadded. A database of delivery codes may be especially useful formanaging the delivery codes and ensuring that a particular correspondentis not provided with more than one delivery code. For example, thereturn address field (or other field of a message designated forproviding delivery codes) may be checked when every message is sent by auser. Any delivery code found may be looked up in the database andcompared with the recipient's name and address. If the recipient and thedelivery code do not match, the user may be alerted to the discrepancy,or in the alternative, the discrepancy may be repaired automatically byreplacing the delivery code with the valid code previously provided tothe recipient. Similarly, if the message sent lacks a delivery code, thedatabase may supply the delivery code found in the database for theindicated message recipient, or alert the user if the recipient is notfound.

In an embodiment of the invention, new delivery codes may be generatedautomatically or semi-automatically. Automatic generation of deliverycodes may be particularly useful, for example, in corresponding withothers from whom a very small volume of return mail, such as a singlepiece, is anticipated. Addressees may not desire to take the time todevelop a customized delivery code for such correspondents, but at thesame time, may want to ensure that any return correspondence is not lostin a junk mail folder, or other generic mail folder. Automaticgeneration of codes may be triggered by a specific, defined actionperformed by a user, such as, for example, sending a mail message withno delivery code in the return address field, or pressing a “generatedelivery code” button at some time during the process of composing orsending a message. When the addressee performs the defined action, amail browser or similar application may generate the code automatically,and insert the automatically-generated code in the return address orother appropriate message field.

Various methods may be used to generate a code automatically. Forexample, the recipients name or a defined number of characters thereofmay be combined with a specified number of random characters and/or arandomly selected word. Such an automatic method may generate, forexample, a delivery code of “janed8g7puff” for a recipient named“janedoe.” Preferably, the automatically generated code is then saved ina database in association with the recipients name and mail address,like delivery codes generated manually.

If, at step 410, a request to revise a code and/or any associatedinformation is detected, the code or associated information is revisedat step 412. One way to provide for revision is to present the user witha selection list of available codes. The user is permitted to select acode from the list, for example, by “clicking” on a code in a drop-downlist. The established code and any associated information then appearsin an appropriate revision box of a revision window, where the user mayalter the desired characters. When finished, the user signals completionof the editing process, such as by pressing a “done” button. The revisedcode is then validated and established as described above. Revising acode achieves the same result as deleting a code and adding a differentcode, although the sequence of steps followed in a revision process maybe more convenient for users in some situations.

Similarly, if a request for deletion of a code is detected at step 414,the requested code is deleted at step 416. Users may desire to deletecodes when a particular folder begins to receive too much undesiredmail. In effect, deleting a code is like deleting one of a user's emailaccounts, but is preferably more convenient than deleting an account. Aprocess for deleting a code may begin much like the process describedabove for code revision, i.e., presenting a user with a selection list.The selected code may then be deleted by removing it from a list ofvalid codes. In an embodiment of the invention, the removed code and anyassociated information are retained in a list or database of obsoletecodes. After a code has been deleted, the user preferably has the optionof deleting any established mailbox folder labeled with the deletedcode, or in the alternative, retaining the folder for archival purposes.The list or database of delivery codes is then closed, completing theexemplary code-defining method 400.

When a code is deleted or revised, it may be desirable to informselected correspondents of the change. Various methods may be used toinform selected correspondents, such as by informing them manually.However, it may be preferable for a mail system to include a functionfor automatically informing correspondents of a user of a change orremoval of a delivery code. The database of delivery codes may be usedfor this purpose, in conjunction with a delivery code manager function.When a code is deleted or changed, the manager function may consult thedatabase to obtain the names and addresses of all correspondents listedin association with the prior delivery code. A message may then beautomatically generated and/or sent to the correspondents, informingthem of the change. Optionally, the manager function may prompt the userto approve the sending of the notices, to ensure that undesiredcorrespondents are not alerted to the change. When the correspondents tobe noticed are served by the same mail server (or other system ofequivalent capability) as the user, it may be further preferable toinclude a function for automatically updating the address books of thecorrespondents. For example, when a change in delivery codes is made,the manager function may cause a “pop-up” message to be delivered to theassociated correspondents on the server. The message may provide abutton or similar device for the recipient to activate, such as byclicking on with a pointing device, thereby causing the manager functionto automatically update the recipient's address book with the newdelivery code information.

FIG. 5 shows exemplary steps of an alternative method 500 for providingan addressee an option to define delivery codes semi-automatically.Method 500 is intended to provide for setting up codes “on the fly” in areturn address field accessible at the sending end of a mailtransaction. For example, in an email system, the return address field(or other field designated to contain delivery codes) should be visibleand accessible in a message composition screen of the user's emailprogram, like an addressee or “cc:” field. In an email system, thereturn address field may be especially suitable for containing prefixeddelivery codes, for compatibility with existing email systems. Suchprefixed codes will be treated by existing mail systems as part of theaccount name. However, at an addressee mail server configured accordingto the invention, the prefixes will be recognized as delivery codes. Thereturn address field may have the user's root address as its defaultvalue, with established delivery codes easily selectable, such as byselection from a drop-down list. Method 500 may then operate to providethe user with an option to set up a new delivery code by typing the newdelivery code in the return address field. The method may be readilyadapted to function with separate delivery code fields as well.

Method 500 may then operate by scanning the return address field of sentmail, as exemplified by the following steps. At step 502, a piece ofmail is received from an addressee client who has submitted the mailmessage for delivery to another addressee of the system. At step 540,the return address field (or other separate field for delivery codes) isread. If no delivery codes are found at step 506, the mail is sent toits destination at step 516. If a code is found, the sender's deliverycodes are accessed at step 508. If a match is found at step 510 betweenthe delivery code on the piece of mail and a code in the senders list ofestablished codes, the database or list of delivery codes is closed atstep 516 and the mail is delivered to its destination at step 516.Optionally, the delivery code may be checked for consistency with thepast delivery code provided to the designated mail recipient, and thesender may be alerted to any discrepancy. If no match is found, thedelivery code identified on the piece of mail is added to the sender'slist of delivery codes. Optionally, the sender may be prompted toconfirm or cancel the addition of the new code, and/or be prompted tosupply any desired associated information. The code and any associatedinformation are then added to the list at step 512, the list is closedat step 514, and the mail is delivered at step 516. Thus, the user maybe given the option of establishing new delivery codes automaticallyupon the occurrence of certain events, such as at the time of composingor sending a mail message.

FIG. 6 shows an exemplary view screen 600 for use with a system andmethod according to the invention. The view screen is configured for usewith an email application running on a client (addressee) computer of anemail system. Screen 600 comprises a title frame 602, a directory frame604, and a message list frame 606. Additionally, a frame for messagecontents (not shown) may be provided. Directory frame 604 may display aplurality of folders, such as inbox folder 608 and outbox 610. Thefolders are preferably organized into a directory structure 614.Lower-level folders within a particular folder or directory preferablymay be displayed or hidden at the users option. In FIG. 6, the foldersin the inbox 608 are displayed. These folders may be labeled withdelivery codes, such as folder 612 labeled with “4MYPALS.” A separatefolder, such as the “JUNK” folder 616, may be established for mailreceived without a valid delivery code. Folders containing new unreadmail may be flagged, such as with an icon 618.

Although FIG. 6 shows a plurality of hierarchical folders organizedaccording to delivery code, users are preferably provided with an optionto view received messages in a list format, such as in reversechronological order, irrespective of the delivery code. It may still bepreferable to segregate mail lacking a valid delivery code from mailwith a valid delivery code on the list. The delivery code may optionallybe indicated, such as by an icon or spelled out, on or adjacent to eachline item of the list. The list format provides the advantage ofallowing the user to quickly scan all received messages to identify themost urgent or most interesting messages. Accordingly, it may bepreferably to provide users an option to toggle between a combined listview and a directory view as shown in the directory frame 604. Forexample, a toggle button (not shown) may be provided. Alternatively, thedirectory frame 604 may be configured so that all files contained in aroot folder and any subdirectories are listed together when a rootfolder is highlighted. Less preferably, the directory view may beomitted altogether.

In an embodiment of the invention, a user may view a list of messages620 within any given folder by selecting the desired folder. Forexample, in FIG. 6, the “TED&SAL” folder is highlighted, and the list ofmessages 620 in this folder is displayed in the message list frame 606.The list may be displayed in any suitable format. For example, the listmay display selected message fields such as the identity of the sender,a subject line, and message date. The contents of any message maypreferably be viewed by selecting a message from the list, for example,message 624 (shown highlighted). Thus, the example illustrates how amethod and system of the present invention may be readily implemented inan email system using a mail interface like those currently preferred bymany computer users. Of course, a wide variety of other user interfacesmay be designed and used with the present invention, without departingfrom the scope thereof.

Having thus described a preferred embodiment of a addressee-defined mailaddressing system, it should be apparent to those skilled in the artthat certain advantages of the within system have been achieved. Itshould also be appreciated that various modifications, adaptations, andalternative embodiments thereof may be made within the scope and spiritof the present invention. For example, a addressee-defined mailaddressing system for use on an email system has been illustrated, butit should be apparent that the inventive concepts described above wouldbe equally applicable to any mail system. The invention is furtherdefined by the following claims.

1-25. (canceled)
 26. A computer-readable medium containing instructionsoperable with a computer to: receive user-defined codes associated withan electronic mail account that are not used to specify the electronicmail account by a mail server for the electronic mail account; place theuser-defined codes as distinct from and prefixed to a root deliveryaddress specifying the electronic mail account in respectivereturn-address fields of outgoing electronic mail messages, so that eachof the codes comprises a dot-separated character-based prefix to theroot delivery address and appears to be part of an apparent subdividedSMTP address for the electronic mail account; receive incomingelectronic mail addressed to apparent subdivided SMTP addressesincluding the root delivery address; and place respective pieces of theelectronic mail in respective incoming mail folders indicated byrespective ones of the user-defined codes for the electronic mailaccount.
 27. The computer-readable medium according to claim 26, whereinthe instructions are further operable to receive electronic mailaddressed to only the root delivery address without any one of theuser-defined codes.
 28. The computer-readable medium according to claim27, wherein the instructions are further operable to place respectivepieces of the electronic mail addressed to only the root deliveryaddress without any one of the user-defined codes in a default folderfor the electronic mail account.
 29. The computer-readable mediumaccording to claim 26, wherein the instructions are further operable toplace respective pieces of the electronic mail addressed to apparentsubdivided SMTP addresses including the root delivery address that lackany valid one of the user-defined codes in a default folder for theelectronic mail account.
 30. The computer-readable medium according toclaim 26, wherein the instructions are further operable to provide aholder for the electronic mail account with an option to define theplurality of user-defined codes.
 31. The computer-readable mediumaccording to claim 30, wherein the instructions are further operable toprovide a holder for the electronic mail account with an option toinvalidate any of the plurality of user-defined codes.
 32. Thecomputer-readable medium according to claim 26, wherein the instructionsare further operable to discard respective pieces of the electronic mailaddressed to apparent subdivided SMTP addresses including the rootdelivery address that lack any valid one of the user-defined codes. 33.The computer-readable medium according to claim 26, wherein theinstructions are further operable to place the user-defined codes in therespective return-address fields comprising “from” fields.
 34. Thecomputer-readable medium according to claim 26, wherein the instructionsare further operable to place the user-defined codes in the respectivereturn-address fields comprising “reply-to” fields.
 35. Acomputer-implemented method, comprising: receiving user-defined codesassociated with an electronic mail account that are not used to specifythe electronic mail account by a mail server for the electronic mailaccount; placing the user-defined codes as distinct from and prefixed toa root delivery address specifying the electronic mail account inrespective return-address fields of outgoing electronic mail messages,so that each of the codes comprises a dot-separated character-basedprefix to the root delivery address and appears to be part of anapparent subdivided SMTP address for the electronic mail account;receiving incoming electronic mail addressed to apparent subdivided SMTPaddresses including the root delivery address; and placing respectivepieces of the electronic mail in respective incoming mail foldersindicated by respective ones of the user-defined codes for theelectronic mail account, at the mail client.
 36. The method of claim 35,further comprising receiving electronic mail addressed to only the rootdelivery address without any one of the user-defined codes.
 37. Themethod of claim 35, further comprising placing respective pieces of theelectronic mail addressed to only the root delivery address without anyone of the user-defined codes in a default folder for the electronicmail account.
 38. The method of claim 35, further comprising placingrespective pieces of the electronic mail addressed to apparentsubdivided SMTP addresses including the root delivery address that lackany valid one of the user-defined codes in a default folder for theelectronic mail account.
 39. The method of claim 35, further comprisingproviding a holder for the electronic mail account with an option todefine the plurality of user-defined codes.
 40. The method of claim 39,further comprising providing a holder of the electronic mail accountwith an option to invalidate any of the plurality of user-defined codes.41. The method of claim 35, further comprising discarding respectivepieces of the electronic mail addressed to apparent subdivided SMTPaddresses including the root delivery address that lack any valid one ofthe user-defined codes.
 42. The method of claim 35, further comprisingplacing the user-defined codes in the respective return-address fieldscomprising “from” fields.
 43. The method of claim 35, further comprisingplacing the user-defined codes in the respective return-address fieldscomprising “reply-to” fields.
 44. A method for disposition of electronicmail, comprising: reading a delivery address associated with a piece ofmail, wherein the address comprises a root delivery address of theaddressee for the piece and a delivery code defined by the addressee;extracting the root delivery address and the delivery code; actuating asoftware process identified by the root address; processing the deliverycode using the software process; and updating a user account based onthe contents of the delivery code.
 45. The method according to claim 44,wherein the delivery code and root delivery address are encoded togetherusing a formula that permits them to be separated within the softwareprocess.
 46. The method according to claim 44, wherein the delivery codeis a dot-separated character-based prefix to the root delivery addressthat appears to be part of an apparent subdivided SMTP address for theelectronic mail account.
 47. The method according to claim 44, whereininformation sufficient to uniquely identify an account is embeddedwithin the delivery code.
 48. The method according to claim 44, whereinat least one instruction executable by the software process is embeddedwithin the delivery code
 49. A method for addressing of electronic mail,comprising: reading a delivery address associated with a piece of mail,wherein the address comprises a root delivery address of the addresseefor the piece and a delivery code defined by the addressee and whereinthe delivery code is a dot-separated character-based prefix to the rootdelivery address that appears to be part of an apparent subdivided SMTPaddress for the electronic mail account; comparing the delivery code toa list of permitted delivery codes; and delivering the electronic mailto the addressee if the delivery code is on the list of permitteddelivery codes.
 50. The method according to claim 49, wherein theattempted delivery of the electronic mail is rejected during a SimpleMessage Transfer Protocol session if the delivery code is not on thelist of permitted delivery codes.
 51. The method according to claim 50,wherein the rejection is made by transmitting a code indicating that theelectronic mail address does not exist.
 52. The method according toclaim 49, wherein the electronic mail is delivered to a secondarylocation if the delivery code is not on the list of permitted deliverycodes.
 53. The method according to claim 49, wherein the electronic mailis returned to the sender as undeliverable if the delivery code is noton the list of permitted delivery codes.
 54. The method according toclaim 49, wherein the electronic mail is returned to the sender with awarning that the delivery code is invalid if the delivery code is not onthe list of permitted delivery codes.
 55. A method for addressing ofelectronic mail, comprising: reading a delivery address associated witha piece of mail, wherein the address comprises a root delivery addressof the addressee for the piece and a delivery code defined by theaddressee and wherein the delivery code is a dot-separatedcharacter-based prefix to the root delivery address that appears to bepart of an apparent subdivided SMTP address for the electronic mailaccount; retrieving disposition instructions from a databasecorresponding to the delivery code; disposing of the electronic mail inaccordance with the delivery instructions.
 56. The method according toclaim 55, wherein the delivery instructions are defined by theaddressee.